Streamline/efficient documentation of color code in part number?

[TGIZINSK]

My company is working to implement the use of ESI to publish to ERP via Windchill Change Notice.

Our current business practice is for Product Engineering to design product, responsible for form/fit/function, then Manufacturing Engineering takes the Design BOM and defines the manufacturing BOM in Windchill.

We are on a journey to change the way mBOMs are built. Previously the End Items, Shipping Unit (parcels), Mechanical Parts and Plant Data were structured in the Windchill mBOM, then a home-grown middleware between Windchill and ERP was used to massage the Windchill mBOM by adding raw materials, semi-finished parts, routing/process information, and addition of -FINISH information (ex PARTNUMBER-BLACK) used for purchasing and inventory of parts with finish.

Going forward a complete mBOM will be build in Windchill and published through ESI; including all raw materials, semi-finished parts, Process Plans, -FINISH parts, and Plant and Enterprise Data.

Today our process leverages Downstream Branches and Equivalent links wherever possible and necessary, where we see both Design and Manufacturing view objects in our mBOMs, this is going to remain as we go forward on our journey.

Product engineering is holding strong on the fact they are "color blind" and does not specify part color in their models/drawings/parts.

This decision is driving the requirement for all -FINSIH parts be authored in the mBOM. As I think about the data architecture, downstream parts, and the maintenance of the data created; I am feeling this is going to create more Downstream Parts and a lot of duplicate effort for our manufacturing friends who will need to mirror changes made in Design on the Downstream Parts that now have unique master data.

In my investigation for this post, I had read many people who post/comment are documenting part color all the way back in CAD (for visualization and re-use downstream).

Are there best practices out there for this scenario? Or instances that folks have experienced and changed course due to inefficiencies or issues down the road?

I appreciate any input as it will help me understand any potentially push for a change where certain information is authored for improved efficiency across the development process.

[avillanueva]

Recommend mining Oleg's site for similar discussions: https://beyondplm.com/?s=part+color. No one is wrong and no one is right. Great topic. This is a matter of perspective. Curious, what's the product you are making? That matters and will drive your solution. In my case. we had a military product that was designed with one color paint in mind, per requirements. A new contract comes along and the paint spec has changed. We do not expect to see every color in the rainbow so we ended up converting some parts to tabulations where the color was a suffix number. This had the effect of rippling up the BOM to upper assemblies to tabulate them in response. Still manageable but you see where this going. Highly dependent on where that exterior facing colored part is shown in the BOM. Here is a good place where eBOM and mBOM can diverge. If it gets too complex, consider looking at Options and Variants.  

[TGIZINSK]

Thank you for the reply and the article, it is helpful to see fundamental ideas laid out to reflect and think upon. We are in office furniture industry, high variation product in regards to options and finishes. We are also implementing options and variants (that was mistakenly left off my original post), where customer configuration will be defined in the eBOM (left hand or right hand (LH/RH) door option), and option set used in the mBOM for selecting parcel 1 (LH) or parcel 2 (RH). The O&V data is also required for new products being published through ESI. The O&V data is also going to need to include finish options.

Some colors are forced (metal shelf is always black), some colors are customer selectable (drawer handle is available in 4 colors), and certain surfaces are open to our entire pallet of color (cabinet exterior body is available in any color we can paint). In our system, if a part is inventoried then we need -FINISH code to differentiate it from other colors of the same part. The shelf and pulls would have finish suffix while the cabinet body wouldn't be inventoried, delivered just in time from paint line to assembly line.

Industrial design or marketing may define the shelf to always be black, the documentation of that decision is captured on engineering drawing specification then it is interpreted by manufacturing and a manufacturing downstream part created to add "-BLACK" to new part.

[joe_morton]

Thanks so much for your post. I love learning about the journey that other organizations are on and how they're leveraging PLM to meet business needs.

Right now we're on a journey toward "part-centricity," a concept which may be interesting to you. In the typical "CAD-centric" approach, a model is part number XYZ and if you need another part number, you need another model. It sounds like your organization is getting around that somewhat by defining additional part numbers in the mBOM. 

In the "part-centric" approach, you start with a part number, then add all the documents to define it. 3D model and drawing (ideally) do not specify material or finish. Separate documents are linked to the WTPart in Windchill to define those things. The 3D model and drawing then, would end up getting linked to all the WTParts that have the same geometry (but different finishes). This allows engineering to be "color blind" like you're saying, and it would simplify the mBOM.

So at the end, you'd have a WTPart linked to a model and drawing (that may be reused for other WTParts) and document(s) defining material and finish (that can also be reused on other WTParts). All of the data has to be collected in some sort of Technical Data Package to define the design. 

We're still early on this journey, but I hope the thoughts are helpful.