Classification won't make you Rich, but it might make you powerful
Classification seems like an awful lot of work. Do we really have to set up all this structured data, and do we really have to think so hard about it? Why can't product models just grow more amorphously? Barry L. Walton, Jan. 20, 2006
Copyright:Barry L. Walton ©
Classification seems a lot of work, why do we really have to set up all this structured data and think so hard about it? Why can't modeling grow more amorphously? Read on to determine whether you are in the camp of start simple and grow your model or the camp of think long term and get it right as much possible from the start. As we CWGer's are into bicycles, you can imagine what happens when lack of discipline in modeling at the bike factory results in your racing bike being delivered with tricycle handlebars, child's pedals, and no chain. This article touches on more advanced topics in classification and hopefully provides advice on how to build a solid product model that can grow over time without significant and difficult or impossible re-work.
By:Barry L Walton
Barry L Walton Consulting
12 Years as a senior consultant on mySAP ERP implementations
30+ Years as a technical professional and consultant
12 Years using SAP VC/IPC technology
Located in USA
+1 530 613-0659
We continue to build our modeling knowledge around the ACME BICYCLES Company. Here focusing on classification again. In Steve Schneider's recent article Class Inheritance Won't Make You Rich, he emphasized the need for a solid classification system. Here, we explore some of the implications of the classification system that extend beyond sales modeling (a more frequent discussion topic in the CWG).
It's Christmas and you have just been given the unique opportunity of entertaining your grandchild. It occurs that you can solve this and some other problems by buying a new bicycle. However, you must also complete your Christmas shopping and you don't think that a behind the seat carrier from the local kid store will cut it. While watching a Christmas movie, the commercial from ACME made you think…"I can get a new racing bike (fun for the long term) along with a behind-the bike carrier. It'll hold my grandson and the presents I need to buy. Heck, I can go shopping, entertain my grandson, and exercise at the same time". Sold!
ACME Bicycle bought its own Christmas present early…my SAP ERP along with the mySAP CRM configurator and sales toolsets. From the earlier articles by Steve Schneider, you know already that the classification system is a critical component of your master data design. And if you were lucky enough to visit the CWG meeting at Marcos Island this past November, I alerted you to some of the pitfalls and opportunities in my presentation.
I start with the general background and need for you to pay attention to classification. I'll define terms relying on the SAP approach and methods. I'll provide, hopefully, guidance in setting up the classification system and its elements.
With the information provided here, you should be able to approach more advanced implementations with a structured approach that does not require major rework.
ACME Bicycle Company, who with their rapidly expanding products and sales and manufacturing systems requirements needs to 'model' a broad set of products and services.
In the sales world or sales view of the data, customers are choosing features of a product and in more advanced situations configuring multiple products that are interrelated. The mySAP Configurator (VC or IPC) creates the result based on the Grandfather's choices. The resulting sales order (and perhaps some additional information linked to the sales order) is then passed to the mySAP CRM/ERP supply chain for manufacturing or assembly. The data must be interpreted by mySAP-enabled supply chain to provide, for example, a bill-of-material to manufacturing.
Classification is very important for supply chain modeling as well for sales configuration modeling.
To take full advantage of classification it is important to plan it with your future business in mind. A short-sighted approach to classification can easily create re-work that is extremely difficult and time consuming, particularly in mySAP ERP. Done well, the classification system provides the backbone to your product model. One that is powerful, flexible and easy to expand.
First some background on ACME Bicycles and their approach along with additional definition of terms.
ACME Bicycles began simple. They made a simple tricycle, one size and one color (red). No modeling was needed. They needed only to focus on marketing a single product (in retail this is called a SKU). However, the company had visions for the future and knew they would have a much broader product set over time. They also understood the problems of modeling re-work as well as the challenges.
The bicycle system desired by the grandfather is complex and meets several needs. From a modeling perspective, each of the major items is separately configurable such as the size of the bike and the number of passengers in the carrier. The items need to fit together and be supplied with any necessary accessories such as connectors and warranty services.
ACME needs to create not only a sales order with the correct items, but it must also to have a perfect bill-of-material for manufacturing. By so doing, the products as a group can be built by the factory to minimize and simplify assembly by the buyer. A perfect bill-of-material also reduces manufacturing costs. ACME can avoid expensive generic assembly kits that must have special instructions and tools to assemble it after delivery.
We approach to the classification model from ACME Bicycle's perspective.
Initial Set Up
ACME is in a growing business including sales and manufacturing. ACME desired to use the classification system to solve a number of business requirements including product and materials planning and manufacturing in addition to sales. The key to a solid start is the breadth of vision for the design and use of the classification system, which may include products (the marketing view) as well as parts (the manufacturing view). We build further on the examples in Steve Schneider's Class Inheritance Won't Make You Rich where he describes two kinds of bicycles: racer and mountain.
To satisfy the needs of our grandfather, who will need both a racing or road bicycle, with a trailer that can hold a passenger and other items, ACME needs to configure each item, add necessary or recommended items to the sales order, and finally add specific non-ordered items in manufacturing bill-of-material for accurate assembly. In so doing, complexity and costs are minimized and accurate products built and shipped more quickly.
Overall approach by ACME
The road bicycle must be configured to the size/weight of the adult. It must also include pedals, seat post equipment, wheels, and tires that handle the extra weight and trailer. The trailer must be sized properly and equipped with the correct towing parts to connect to the bicycle. ACME also envisions selling many parts of this solution as 'products' for customers and bike shops. ACME wants an upgrade and repair business.
AMCE needs to classify a broad assortment of products from the manufacturing and sales perspective. Many of the parts of the solution may be sold standalone at some point in the future as well (such as replacement wheels, tires, and pedals). Characteristics are needed to describe the variations and attributes of the various bicycles, trailers, accessories, and services.
ACME wants to provide considerable flexibility to the buyer (they may want to assemble or further customize the product as well has have factory assembly) while allowing all the materials such as packaging, assembly kits, and services to be determined without the customer needing to "order" them as specific sales items.
In other words, the customer wants a simple shopping basket describing the solution, not a parts list. To optimize manufacturing, ACME wants mySAP ERP to provide accurate, automatically generated parts lists based on the sales order content. This eliminates manual review of the order to hand pick appropriate parts.
Given these requirements, the modeler needs a comprehensive approach to the class hierarchy and needs to avoid rework as the business requirements expand.
We'll begin by describing basic concepts and definitions before proceeding to the classification system design.
This section defines terminology and context for the data elements along with graphical standards consistent with other CWG publications. We will discuss the following objects and concepts;
- Class hierarchy
- Dependency Rule & Rule Nets
A class in SAP is a master data object that is used as a means of describing other data objects such as materials. By attaching the material to a class(es) enables the characteristics of the class(es) to define attributes of the material. The manner of assigning these characteristics their values specific to a material is well described another article by Steve Schneider . For Variant Configuration (VC), class type 300 is the standard SAP-supplied class type. Class type 001 is another class type that is often associated with materials. Classification data in class type 001 is generally not available to high-level VC modeling for sales configuration and mySAP ERP/CRM sales order entry. Both class types can play a role in modeling for manufacturing and production as we will discuss later in this article. The excellent SAP Online Documentation provides extensive further information.
|TIP:The allocation and assignment of values can be thought of as extending the SAP standard material master properties (the class view in mySAP ERP can be viewed through the material master viewer). Each master data class has attributes of its own including a 3-digit numeric type. Each type is linked to specific business processes in the mySAP product suite.
Characteristics are also master data elements. Since they are independent data they can be linked as needed to any class (the classes do not need to be of the same class type).
Characteristics have a type that determines what kind of values can be assigned. These types include character (char), numeric (num), and in the IPC advanced-mode include abstract data type (ADT), Boolean, aggregation (num), and balance (num). These are the more common types used by the modeling community. Here we focus on the standard character and numeric characteristics.
|TIP:This independence is an important concept. You really need to consider this generality and possible use of the characteristics as you create them. Once allocated to classes and used by the SAP applications, many master data attributes are difficult to impossible to change or delete. SAP generally intends that you will add (and maybe delete) values in a characteristic and that's it. As in surgery, characteristics can be considered powerful but sharp instruments! I strongly advocate taking advantage of the re-usability and sharing of characteristics.
Materials play an extremely important master data role in mySAP applications. Materials (visible as the material number) not classes appear in the sales orders transactions and in manufacturing and sales bills-of-materials. Attributes of the material determine its relevancy to sales and/or manufacturing. But it is important to correctly classify materials as VC/IPC-modeling relevant class type 300 and/or as non-modeled sales or manufacturing materials into the class type 001. Don't think of materials as a 'hierarchy', rather materials are classified. A bike or a wheel you sell are materials (a modeler might think of it as a class, but classes don't appear in the sales order or in the manufacturing bill-of-material).
A class hierarchy is a group of classes linked by master-data parent class to child class relationships. An isolated class not linked to another class is not part of a class hierarchy. In the mySAP master data design, a child class always inherits all the characteristics of the parent class(es). The values of each characteristic as it is inherited can be changed or assigned in various ways (refer to article on assigning characteristic values).
In some of the mySAP application transactions, the inherited characteristics are distinguished from those directly allocated by a color scheme in the GUI. In the graphical scheme and examples here, inherited and directly allocated characteristics (cstics) are distinguished by color.
The class hierarchy dramatically simplifies maintenance and makes characteristics more powerful by allowing allocation at any level in the hierarchy. Inheritance of these characteristics is then applied by the mySAP classification system automatically to all child classes and the materials allocated to the classes. Imagine a new characteristic that can be added to the bicycle class rather than individually to 500+ bicycles.
|TIP:Deleting characteristics that are inherited is difficult or impossible depending on the class type used and the mySAP transactional and master data that has been assigned. For example, orders in the ERP or CRM sales backlog have characteristic values assigned in an order-specific data structure that can be corrupted by deletion or modification of inherited characteristics…another reason for careful hierarchy design principles and approach.
|NOTE:One very strong recommendation is that you use mySAP engineering change masters (ECM) to perform all classification create/change transactions. This protects the hierarchy, in that without such protection you may find yourself backing it up after changes, particularly those that affect inheritance and class-to-class assignments. Without ECM it can be very difficult to reconstruct the hierarchy and as well any dependency rules that depend on the hierarchy will go into a blocked state. Debugging such an inadvertent change can prove challenging at the least. Be sure to assess any implications on the IPC before turning on ECM on the hierarchy. In the VC environment, ECM works very well and helps ensure data integrity.
Dependency Rule & Rule Nets
In the VC and IPC, the real guts of rules depend on characteristics and values. Classes alone are the main objects referenced in the rules; however, it is characteristics and their values that both drive a rule and its results. Each rule is its own master data and (except for rules within rule nets) can be allocated in many places within master data.
The ACME Bicycle Classification System
ACME will sell many kinds of "products"…because in mySAP anything you sell as an order line item pretty much becomes a material (where you can attach prices, bills-of-materials, and so forth). Classes are not used directly in transactions. The ACME modeler took the following approach:
The modeler knew that ACME is starting with a simple sales model (pre-determined SKUs), but that over time ACME will expanding into after-market sales, services, and configure- & make-to-order bicycles.
Naming conventions are very important in classification. Once created in mySAP, they are very difficult or impossible to change once business transactions use classification. Using somewhat readable formal names (descriptions are easy to change) ensures uniqueness (in this case preceding all names with A_ for ACME). For example, ACME may need a joint modeling environment with subsidiaries or new parent companies who might have used similar names like PROD or ACCESSORY.
|TIP:Setting up the top-level company node and assigning an explicit typing characteristic A_TYPE (products, services) to the main node allows each service and product (when they are materials to be specifically seen (in material master view) as either a product or a service. Implicit typing means referencing the class name, which becomes more complex to determine when a hierarchy exists. This concept will be made more clear by examples and further discussion below.
The characteristic A_TYPE enables immediate identification in the material master of a product (or service) that it is a service or a product (otherwise, you must look at the hierarchy all way from the material (a child) through its various parent classes or the material description to find out if it is a product or service. Such "searching" is extremely inefficient in a complex hierarchy. The modeler in sales configuration often "infers" such values via VC and/or IPC rules. However, such rules do not execute in the master-data world and provide no help at all to find, search, or sort materials. The latter task is a frequent requirement in the planning and financial worlds.
Two specific actions were taken by the modeler:
- Creating a explicit characteristic that defines subclass types AND
- Restricting the range of the characteristic as it is inherited.
For the products sub-branch, serv(ices) was removed from the value domain of A_PROD(ucts) and visa versa for services. The same principle is then applied as each time new subclasses are created and assigned. In the end, the lowest branch will have several of these 'typing' characteristics assigned.
This might at first glance seem like a lot of extra data; however, in a well-designed hieararchy, the number of levels of the hierarchy should not be more than 6 to seven levels. By comparison, the biological hierarchy system has many, many more diverse types of trees and flowers, insects, birds than most companies could ever offer and it is only 9 levels deep (a specific species is the "tenth" or material level in the mySAP modeling world). If your hierarchy is too deep, consider the quality of your design with an eagle eye. With a hierarchy 5-7 levels max, only 5-7 explicit characteristics are needed on any branch (at the lowest level). This is a tiny amount of data in most hierarchies and provides incredible reporting and analysis benefits. Linnaeus, who invented the biological classification system in 1753, anticipated the generality and his system most likely will outlive ACME bicycles! Our modeler is using this very solid approach.
The ACME modeler needed the hierarchy to be much broader to solve the Christmas purchase AND to support sales of upgrade products and accessories as well as service
In Steve Schneider's article, he correctly modeled seats, color, handlebars, frames as characteristics applied to the two bicycles as materials linked to a bicycle class. In this particular modeling approach, he also introduced classes to contain the characteristics for seat-type, frame-type, and so forth. For simple sales modeling, this approach can work well. However, in this article we are approaching the classification system directly to more generally meet mySAP needs.
To simply this article, we focus on a subset of the full ACME hierarchy (looking at the Frame, Seat, Pedals, Carrier). Note that we are taking an approach that looks at each material ACME can (or could) sell as either assembled into a solution as a manufacturing part OR as an upgrade part. The approach in Steve's article focused on the bicycle and its sales attributes. He also uses multiple inheritance (characteristics of each racer or mountain bike gets it's characteristics from a class (or material) with more than one parent class. Here the ACME modeler faces a very general modeling case and we will return to the topic of multiple inheritance later. We will also step back to Steve's model for comparison in the conclusion.
In Fig. 3, further sub-branches are added for some of the accessories and products. Whenever the first new subclass is added, the parent class also gets a new subtype characteristic that describes what is special about the subclass(es). The number of values in this subtype characteristic should match the number of subclasses exactly. Note that a bicycle in the A_Bike hierarchy is a fully assembled bike while the frame (replacement parts) appears in the A_ACC accessories branch. These two classes should share color and frame size characteristics at the very least.
In Figure 3, you will notice that the range of the explicit typing characteristics is narrowed to 1 value on the lower-level Class. This is an important aspect of simplifying maintenance and actually helps enable explicit typing. Restricting Cstic Domains article technique 3 describes this method in more detail. Many, many business transactions and reports in mySAP applications do not invoke the Configurator. And so for a modeler who needs other business users to have access to classification data, it is very important that classification facts be maintained directly in the classification system. If you do not do this up-front master data range restriction or assignment, you cannot use, for example, the built-in classification-based search tools in mySAP ERP.
Using the classification system, you can assign values to a material either statically (the values are fixed and best thought of as facts about the material) or dynamically in the IPC or VC. There is considerable power in the mySAP suite as a whole in setting up these facts about a material at its outset.
In Fig. 3 you will note that the material has values assigned, this is a subtle difference from narrowing the range down to 1 value (which can be done in class-to-class links). The specific assignment at the material level must be done in the material-to-class link. When performed here, all SAP reports and search methods for a material work properly and in the VC and IPC, end-users as well as the model can rely on these values as facts. The values assigned cannot be changed (except by the material-to-class maintenance transaction).
mySAP classification allows for many characteristic types as defined above. Within the context of setting up the classification system, it is very important to create them properly at the outset, as adding new values is the only thing that can be done easily. A piece of advice given by the CWG best practices that is worth repeating here is to avoid at all costs overriding characteristics within the assignment to classes. If you do this, it can cause extreme maintenance complications within the hierarchy and my recommendation is that you add new values via characteristic maintenance and that any restrictions of the values be done via the CWG best practices guidelines.
|NOTE:An additional facet of characteristics that is worth noting here is the attribute of 'restrictable'. While this attribute significantly aids IPC/VC modelers, at one time it was thought to add overhead to other uses of the classification system in mySAP. However, my experience is that this is NO LONGER TRUE and that when designing characteristics for use with the classification system that you should make characteristics restrictable from outset. Be very careful in using restrictable multi-valued characteristics as these can cause other modeling issues.
The real power of the hierarchy is that you can add as many characteristics as you need to define attributes of products and services in detail. This detail in mySAP can be static (facts) or dynamic (determined by the VC or IPC). In either case, the characteristics must be assigned to a class to be useful. The best way to do this in the context of a hierarchy is to move the characteristic as high in the hierarchy as possible. This is how Linaeus did it as well. Let's look at a simple example for our bicycle hierarchy (borrowing some of the characteristics from earlier CWG articles):
You should be able see that modeler did NOT move UP the hierarchy to the accessory class all the 'local' or specific characteristics that define a specific accessory type. For example, A_SEAT_TYPE isn't very relevant to other accessories. Adding characteristics one-level too high results in inheritance to subclasses that are meaningless AND you would need the value of "none" or not applicable (n/a) in the value range of the characteristic. The extra overhead of dealing with too many non-relevant characteristics can severely impact performance and make a specific product or class rather confusing when it shows useless and unrelated characteristics.
Note that modeling connections (of any sort) can become quite complex and the classification example here ignores this rather important modeling task. In IPC advanced mode, abstract data type (ADT) characteristics provide a powerful approach to the modeling of connections between objects as classes. The logic of assigning ADTs generally will follow the advice here regarding placement in a hierarchy.
While the use of explicit typing characteristics is especially beneficial in reporting, they can also prove useful in modeling in constraints. The following example illustrates the concept using the hierarchy:
warranty is_a (300) A_SERVICE,
accessory is_a (300) A_ACCESSORY
warranty."length in months" = 12
If accessory.A_ACC_TYPE in ('seatpost', 'seat'),
warranty."length in months" = 36
If accessory.A_ACC_TYPE = 'frame'
Of course, using tables in the restriction is often recommended, but you should get the idea. You do not need to specifically mention each individual accessory subclass in order to infer or restrict values.
In classification, the value domains are one very important modeling decision. We spoke earlier of domain restrictions and the usefulness of restricting them in master data when using the classification for reporting and other search tools outside the configurator execution environment. One subtle aspect of modeling is whether values such as "not applicable" or "zero" are useful or even necessary.
Here are two considerations to keep in mind:
- Having a value of "not applicable" or "zero" can allow you to remove all the other 'real' values and still be able to explicitly state a value in classification. This avoids a modeling issue that can arise when a characteristic has no value assigned. The assignment of the value "not applicable" can be particularly useful in the VC which only allows a "null" or not-specified value to be modeled within certain rule types such as a selection condition. The null or not assigned value cannot be assessed within a constraint. When using constraints an explicit value of zero or null can become critical to modeling, particularly in the VC.
- Having a value of "not applicable" or "zero" does result in those values being stored within the sales order and any resultant history. A characteristic with a null value (no value assigned) is NOT stored. For this reason, it is very important to determine whether you have a large number of "useless" values on any particular class as this can have very adverse affects on the amount of data stored in sales order history (mySAP logistics information system for example). Large numbers of numeric characteristics in particular are often better left in the null state rather than with a value of zero.
Default values can certainly aid in constraint modeling. But overuse, when the values do not have a specific modeling need, can result in very significant increases in the LIS database if you have products that for a given sales order leave many of the characteristics "unused" from a business perspective. Separating User-Relevant Characteristics from Other Characteristics
ACME now has many internal users needing additional facts about the products and parts that make up the bicycle. The modeler must make some critical decisions in this area, taking into account the use model for each material (and class), the needs of his customers buying bikes, and the customers of his data within ACME.
mySAP classification provides two general methods of separating characteristics by use:
- Visual and printing control in mySAP supported transactions
- Dynamic display control in the VC and IPC
Visual and printing control in mySAP
In maintaining each class, two special features are important to understand:
- Organizational Area
- Printing Control
Organizational Area was created to provide easy filtering of characteristics based on roles and responsibilities. For example, in mySAP ERP, up to 8 organizational areas can be assigned per class. When using a hierarchy, it is important that all the classes have the same organization areas assigned (they are not inherited from the parent class as are characteristics). The second step is performed in customization, where each user login-id is associated to one or more organizational areas. The third step is to assign to each class (this is done in the maintenance GUI for characteristic assignment) 1 or more organizational areas as represented in master data by a character to each characteristic. A final step (if you desire that these org areas filter the display in the VC for characteristic value entry), assign the specific org areas that define the default view.
For example you could take this sound approach:
- Org area C - Assigned to customer operations personnel AND product data team, planners, and finance team members (everyone wants to see what the customer sees)
- Org area D - Assigned to the product data team
- Org area P - Assigned to planning team
In mySAP classification maintenance you can specify in the characteristic to class allocation the following indicators:
These indicators (check boxes) are then queried by the application (often a user-supplied program) to help you sort out which characteristics are important. A short note on this topic is supplied in the mySAP Online Help Portal in the Classification documentation under the basic maintenance section for entering characteristics. mySAP also provides an additional (obscure) method of classifying characteristics (use the class type for “classification”) to provide additional user-defined meaning to the assignment of a characteristic to a class. For example, you could then flag certain characteristics as “manufacturing” or “support” relevant. But this data, while it can be seen in classification master data, would need to be handled in printing or reporting via programs that you supply.
Dynamic display control of characteristics
The VC and IPC have various methods of displaying characteristics that depend on master data settings in the classification system and as well on dependency rules. Best practices for this control are not discussed here. One method that I strongly discouraged is the use of pre-conditions to determine whether to display or not display a characteristic. This can be particularly difficult if you need to also minimize the use of the null state of a characteristic to simplify the LIS data. Preconditions force you in the mySAP VC to have a value assigned under common conditions. Also, assigning pre-conditions directly into the classification system can also become very difficult to maintain and analyze. Refer to the best practices guidelines on restriction characteristics.
In the VC, default organization areas are assigned in the material's configuration profile. Implementing the organizational areas properly can then make it very easy to hide modeling characteristics from user-entry characteristics. You can override these defaults if as a user you are a member of the right organizational areas and you use the display controls in the sales order entry and/or configuration simulation screens. That override can be particularly important for easily debugging the model results that are based on user input.
Using the VC to implement your bill-of-material design in mySAP ERP is very powerful and requires that characteristics be present on the materials that are modeled. By 'nesting' a broad array of material choices for each bicycle within the configurable material, you can:
- Simplify the number of bills-of-materials
- Take advantage of the customer's (or modeler's) characteristic values to select the correct materials based on the size, color, and model of the bicycle.
- Add additional characteristics that are only of use to manufacturing (infer these characteristics from the customer's choices for example).
The class hierarchy provides an efficient and powerful way to introduce new products in a consistent fashion. By simply adding them to the hierarchy all their characteristics appear immediately. Leveraging of the bill-of-materials between similar products is also enhanced, particularly if the product model is being used to drive manufacturing characteristics using constraints.
With bills-of-materials driven by the VC, planning considerations need to be taken into account. In mySAP ERP and APO, characteristic value planning is enabled. By directly planning characteristics, the planner avoids understanding the bill-of-material in detail and the system will create component demand. By placing products into a well design hierarchy, consistent product definition helps materials planning along with the more obvious uses of the hierarchy to deal with sales statistics and other reporting.
Advanced modelers will note that up to this point, multiple inheritance was not discussed. Steve Scheider's article referenced at the outset shows several simple, but excellent examples of modeling the bicycle using multiple inheriteance. However, his article does not describe in detail what then happens if you just want to sell and configure seats, frames, etc. as independent sales-relevant materials in mySAP CRM or ERP.
My advice for modeling a breadth of product types with multiple use models in mySAP, is that each product be placed into its proper branch first using the classic approach described here. Implement a well-thought out type-of design (branches created along form/fit/function lines) before considering multiple inheritance for modeling purposes.
There are several reasons for this recommendation:
- Undoing or re-organizing a complex hierarchy in mySAP CRM or ERP is difficult or impossible enough without multiple-inheritance of characteristics.
- mySAP ERP has a severe performance curve that declines rapidly when there are more than 5-6 parent classes (this decline is pretty independent of the number of characteristics involved) and that the classification system will time out in transactions with more that ~7 direct parent classes.
For this reason, multiple inheritance must be carefully thought through. In a well designed model in mySAP ERP with the VC you should be able to successfully classify materials by limiting the multiple inheritance to 2 -3 classes maximum and even in that case limiting its use within the hierarchy.
What can happen in a large company with diverse products is that considerations for designing the model for the storefronts must be balanced against needs in mySAP ERP for having broad classification. In mySAP ERP, large classification hierarchies with many thousands of materials and many thousands of characteristics can perform quite well in the VC. In constructing models for web, performance of very large models may not allow adequate response for users. When both needs are present, it can result in the need for two separate hierarchies or in carefully defining branch structures.
|NOTE:mySAP provides some rather strong controls on the hierarchy when characteristics are inherited. For example, you can receive messages such as “you cannot delete a characteristic allocation” at a higher-level node when the characteristic is inherited. Similarly, you can receive messages such as “you cannot delete a class-to-class allocation” when characteristics are inherited. This “loop” can sometimes be unsolvable without an SAP-provided OSS note whose installation on your system enables you to forcibly delete a class-to-class allocation. Such action, while occasionally necessary, must be done carefully. A particular consideration is how to make the change without the lower-level classes losing inherited characteristics. One method that often works when changing the hierarchy structure involves careful analysis of inherited characteristics on the upper- and lower-level classes attached to the class you wish to change. This sort of change occurs when moving a node to another branch of the hierarchy. By ensuring BEFORE deleting the class-to-class links that all inherited cstics below the class DO NOT change when the cut is made, you can ensure the integrity of all cstics and value assignments of the lower-level classes (which loses any characteristics that are inherited from the ‘deleted’ higher level class). In this method, you can then go back to the hierarchy structure and delete “duplicate” and now unnecessary characteristics on the old branch.
The mySAP classification system is a very powerful backbone for both mySAP ERP and mySAP CRM. It plays a critical role outside the dynamic modeling environments provided by the IPC and VC. You will do very well in your implementations if you think through your classification designs up front taking into account all the uses it can play. By so doing, you can avoid significant or nearly impossible work to re-implement a different hierarchy structure at a later point in time. It is also important to weigh the needs of modeling configuration as a user experience against the needs of other users of the classification system, such as manufacturing, planning, or financial reporting.