The Service Management Experts
Menu

bom

Home / Posts tagged "bom"

Variant Configuration – BOM Class Nodes

Happy Halloween,

I hope you consider this a treat, and not a trick =)  Today I wanted to talk a little about using class nodes in a variant bill of material.  In the old days, this was using class type 200, however, you are no longer constrained to using just 200, you can use 300 as well.  This is a handy method to dynamically add materials to a variant bill of material.  I’ll start with the how…

First, create yourself a class type 200 or 300, and be sure on the additional data that you check the following fields.

All of the fields are self explanatory, so I’m not going into a lot of details (please comment if you’d like more info).  The really important field is the first check box.  This will allow you to add it to the BOM.  The remaining fields will set some defaults for your and the additional behavior.

Once you have this class add, you need to make sure that the characteristic is either included in the your parent configuration (and is passed to your bom class node ) or is set using an object dependency at the BOM level.

Once you have this, you just need to attach the materials that can be selected using this class.  I prefer transaction CL24N to add the materails, but there are multiple ways to connect the material to the class using the standard classification transactions.  The important thing is that each material you enter needs to have the characteristic values set manually in CL24N.  This is how the system knows which material to replace the class node with.

Hopefully this all makes sense, because the part of the post I really want to talk about is some things to be aware of when using bill of material class nodes.  The first is change management.  If you use ECM to control your variant configuration bill of material, this method completely circumvents that process.  Using the class nodes, you can link and unlink materials with no ECM record.  So you must be aware of the loss of traceability when using this approach.  The second topic is that if you commonly obsolete and superscede materials in your bill of materials, finding where the materials are used can be a challenge as well.  The where-used for class types works, but if you are using CS15, you must remember to check the Class checkmark.  So if whomever is running the where used isn’t familiar that the part is used in VC class nodes, it could be easy to overlook when doing a replacement part.  This could lead to inaccurate BOM’s and confusion on the floor.  THis segways into the whole phasing out of a component on a bill of material.  If for example, you have a component that you will be replacing, but still have 50 pieces in stock that you would like to use up.  Managing the class type and when to change to the new component will be very manual and must be done at the right time by someone monitoring the stock.  it won’t be as simple as the rest of the boms that will be changed automatically using date shifting the of the ECO.

Now, despite this items, it has some very good features.  The first features is the required component.  This is especially useful if  you have order boms.  this is will quickly notify you if the class node failed to find a component (but only if you check the required box, see above).  If you use just selection conditions, you won’t get the easy visibility that component didn’t get picked that you were expecting.  The second cool feature, again related to order boms, is that you can manually find an item for a class node and replace it.  So if there is a component that is close, but normally used, you can manually select it from the list and pull it into your BOM.  this can be especially useful if you have multiple options for a single part, and you manage the part by your stock levels.  Someone can quickly evaluate which part you in stock, and switch the class node to that part (making your promise date look much better => ).

Well, I hope this was a treat for you…  if not, well, I’ll try better for next year,

As always if you need more in depth help, we offer consulting to help you streamline your VC processes,

thanks for reading,

mike

Variant Configuration – Keep BOM Dependencies Simple

Having just gone to the CWG (configurator workgroup) for the first time in many years, I was reminded of my most famous story.  My friend Barry Scott Walton even told the story in his presentation.  He was nice enough to remove the names, to protect the guilty.  Some of you probably even remember this story…  It’s not the peanut butter piehl story, but perhaps I’ll share that one too someday…  This was the story of how Mike Piehl shut down MRP because I used very complicated BOM dependencies.

This was back when I worked for ADC Telecommunications and there was a mad scramble to get all of our CTO product lines converted onto to SAP before the dreaded Y2K.  Well, I was frantically working on product lines, and of course pushing the envelope, because no one ever said not to.  ha ha ha.  It all started on Wed.  I still remember grumblings of MRP being really slow, and wondering if I had done anything.  At the time, I couldn’t think of anything I did…  thursday came, the same issues were still occurring.  Then Friday, it became critical.  MRP hadn’t finished in 3 days, and no one seemed to know why.  After lots of digging, working with planning, IT, and even calling SAP’s platinum hotline, we narrowed down the issue.  We had created about 30 material variants and added a forecast to them.  In a normal world, this wouldn’t have been an issue.  But in my design, I used every tool I could in the BOM to make things work.  Well, my design was spot on.  The problem, which Barry later explained to me, was that MRP doesn’t read complex dependencies in the Bill of Material well.  And when I had a bunch of material variants, all with these complex rules, and then it read them over and over and over (because of the forecast)…  well, let’s just say, I become famous.

As soon as Barry explained the MRP issue (which in my defense was never documented anywhere in SAP), I quickly found a work around to get me by until I could rework all of the selection conditions.  I moved my variant table to a database table.  Now, I do not recommend this approach because you lose the tracability, but we had to do something quickly, and this gave us back the performance to get MRP running again (and still forecast those 30 parts).

The work took significantly longer, because I pulled all of the complex logic out of the selection condition, and moved it to the configuration profile.  This meant more characteristics at the top level, but the trade-off was well worth it.

To this day, I encourage all of my clients to keep it REALLY simple in the BOM.  SAP has done better in adapting MRP to handle variant configuration rules better.  But, in my opinion, you want the configuration profile to do all of the heavy lifting anyway, so this approach won’t steer you wrong.

Anway, learn from my experience…  Keep your BOM rules simple…  don’t add tables, don’t do complicated calculations…  just do simple assignments.  You’ll thank me later =)

Mike