SUMA - where do you put your supplier parts?

[sdrzewiczewski]

We are in he process of implementing the Supplier Management module and one question we've been going back and forth on is where do we put the Supplier Parts.

Originally I was thinking that they would be in the same container that the OEM part was in. But after thinking about it, we have several cases where there may be OEM parts that use the same Supplier Part and live in different contexts. Of course we'd love to avoid that situation from happening but the data we have is the data we're stuck with and all we can do is hope to prevent it from getting worse.

What we are thinking right now is having one library for just Supplier Parts. This works well with COTS parts, but from a security standpoint if we use Supplier parts for our custom parts then we may have to think about more control.

Love to hear how others have this setup and pros and cons to the current method.

Today in production we have 4 pairs of attributes for manufacturer and manufacturer part number. This will give us a lot more power, but will also add more time to inputting the information. So I want to make sure that whatever we come up with it doesn't add to much more additional overhead that starts to outweigh all the benefits that we will be getting from SUMA.

TIA,
Steve D.

Sent from my iPhone

[AL_ANDERSON · Accepted solution]

We use SUMA. We have all of our "Manufacturer Part" parts in an
"Engineering Standard" library. Those parts are managed by a separate set
of authors and library managers than other parts. They have different
access control rules than other parts. We do not use "Vendor Part" parts
at all.

Our "Suppliers" are only in the system to indicate what "Manufacturer
Part" parts those suppliers make. We do not do any management of supplier
states, supplier part lifecycle states, or preferred part status, or even
try to track Supplier addresses (those are maintained in our ERP system).
In Windchill, we only link our "Suppliers" to their "Manufacturer Part"
parts that we then link to our "Solar Part" parts so we know what
manufacturers and manufacturer part numbers supply our standard purchased
parts.

Al Anderson
Solar Turbines Incorporate

[MTH]

HI @AL_ANDERSON 

The single "Engineering Standard" library approach makes a lot of sense, especially for keeping Manufacturer Parts cleanly separated from the rest of the BOM world with their own authors and access controls. That's basically the direction we're leaning too, so it's reassuring to hear it's working well for you.

One thing I'm curious about though — how do you handle the situation where the same Manufacturer Part gets referenced by OEM parts that live in different product contexts? That's honestly our biggest headache right now. We've got some legacy data where the same supplier component shows up across multiple programs, and we're trying to figure out the cleanest way to model that without creating duplicates or causing a maintenance nightmare down the road.

Also, the decision to skip Vendor Parts entirely is interesting. We've been going back and forth on that one. Did you ever feel like you were missing something by not tracking preferred status or supplier qualifications inside Windchill, or does your ERP handle enough of that that it was never really missed?

The other thing your setup got me thinking about is our attribute situation. Right now we've got 4 pairs of manufacturer/MPN attributes sitting directly on the part, which is clunky and honestly hard to report on. Moving to a proper Manufacturer Part object and just linking it sounds like it solves that problem elegantly — I just need to make sure the migration story is solid before I sell it internally.

[avillanueva]

I manage a few libraries and each has a SUMA folder which is defaulting in my template import files. Most all of my MFG and Vendor parts are tied to pure buy items (COTS as opposed to Parts of our own design) and those all get moved to libraries. I have seen the load issues where it complains about parts not being in the same context, in the other library, from where I am trying to link them. Seems like this should not be a restriction since only one exists in the system. That's on PTC to fix.

I have struggle too with vendor parts. We still create them and rely on DLA to indicate by cage code if they are a manufacturer or non-mfg (aka Vendor). McMaster Carr, Digikey, Mouser, Bisco are easy ones to spot. Companies with dozens of locations and cage codes are difficult so it takes some research. I struggled a bit with McMaster Carr since they assign their own numbers and its not possible to know their true MFG source. I ended up creating a psuedo-MFG entry called "Distributor Parts" and creating a MFG part under it and then a vendor part. While you can link just a vendor to an OEM WTPart, the sourcing status shows "No AML". This worked around that. It also helps since while tooling can use this parts, flight deliverables cannot and it makes it easy to spot. 

[lgrant]

Agree with @AL_ANDERSON 

COTS and Standard Components would have different ACL and OIR than your engineering wtParts.

The lifecycles would be different. Example a wtPart that is a Standard would be Production or Released and then maybe Replaced or Removed as the standard that defines them was removed.. 

Keep in mind if your using PDMLink that SUMA items would only have one view. They are what they are and already in the manufactured view.

Also, make sure you have a strong Classification set for all items. Users need to be able to find and reuse.

Best of Luck.

[HV_14518816]

Hi,

In one of the implementations that I recently did on SUMA, the company's NPD Program initiates the BUY parts sourcing. Each of the NPD Program is typically in a Product context. The responsible 'Sourcing Engineer" is also part of the NPD program team. So, as per this process, we successfully implemented to have the "Vendor Part" in the same context as the Product which was originally responsible for sourcing that OEM part (sourced as that vendor part).

This way, there is no need to seperately administer a context , which can be confusing given the program setup.

If a second vendor part is to be sourced, it was never any problem. The context team can be used to control the access.

The Vendor part had a simple CN process to release it (End of Qualify ) as well as changes to Sourcing status  - Preferred or Approved or  Do not Use or any other.

For catalogue parts, we of course had a dedicated library and its maintained by a Library admin.

This setup worked.

I would say, look carefully at the sourcing process and analyse. Also pre-caution, SUMA can never be used for actual Supplier Management, it is rather supports only the sourcing strategy! 

Supplier Management is always in SCM in an ERP!. It can be integrated to Windchill, for example to introduce new supplier object in windchill.

Hope this helps!

Best Regards

Hari