The complexity of Part Management in PDM

by Oleg on July 11, 2014 · 13 comments

part-management-pdm-complexity

How to manage Parts? It sounds like a trivial and simple question. Every manufacturing companies and engineering organization is facing this problem. However, it is not as simple as you might think so. The information about Parts (aka Items) is often scattered between CAD drawings, multiple Excel files, PDM and ERP systems. One of the biggest problem is to how to manage revisions and changes for Parts. I captured this problem in some of my previous writings. Future CAD-PLM and Assembly Version Management; Why versioning is complicated in PDM?; PLM, ERP and Managing of Effectivity; Revisions in CAD/PLM/ERP: Old Problems or New Challenges?

Recent GrabCAD blog – Part Revisions: Deal or No Deal made me think again about why is so complex to manage parts in every PDM environment. The following passage explains what means Part has no revision:

Documentation can be revised, but the part itself should not. If a part changes, the revised part is issued a new part number. In the case of PMI, where the “documentation” portion is integral to the part, revisions are more esoteric. Allowable PMI revisions in that case depend on whether the documentation portion is being updated or the part model is being physically changed.

The following passage explains one of my 5 Don’ts in BOM management - Don’t use the same ID for Part Numbers and Drawing Numbers:

In many cases, the documentation is a fully dimensioned engineering drawing, though these days it might also be Product Manufacturing Information (PMI), if you’re riding the technology wave. In the case of a drawing, the documentation also carries an identifying number. While it may be tempting to make the part and drawing numbers the same, such an approach aims to misbehave. For example, a drawing is often changed for very different reasons than the part it describes, often in a fashion that has no impact on design. In addition, drawings may describe multiple parts. In other words, drawing and part life cycles are unique, so the identification number for each must also be unique.

Now, let me go back to the original question. Why is so complex to manage parts in PDM? Here are two main reasons:

1- Complexity of two lifecycles – CAD and Items

CAD documents and Part lifecycle is fundamentally different. PDM system manage CAD files revisions and dependencies between files. Parts (Items) requires Part Numbers and Effectivity to control FFF (Form, Fit and Function) also known as interchangeability rules. Revision can be applied, but it won’t be used to identify a part.

2- Disagreement about where is “master” of part information and cross system integration

Part information is scattered between PDM, ERP and supply chain management systems. Organizations are having hard time to agree WHO is controlling Part creation process. When changes happens or new parts is created, information must be synchronized between multiple systems. It raises the complexity of overall integration and data management.

What is my conclusion? Complexity of two lifecycle management is a key problem in part management in PDM. It is hard to combine part lifecycle including interchangeability rules and effectivity with proper management of CAD documents. The user workflows are getting complex and engineers are having hard time to use the system. While the reality of manufacturing is that both documents and parts need to managed in an appropriate way, PDM vendors facing real challenges to get efficient Part Management processes in place. Just my thoughts…

Best, Oleg

Share
  • Michael Wm. Denis

    Oleg – wouldn’t you love to do a forensic IT analysis on GM’s ignition switch debacle? I believe they are a UGS shop – or were back in the 90s – but it does go to show that even the best IT doesn’t overcome poor governance of people, policy & process.

    Concur and would add the third lifecycle of Service (SLM) to the complexity of PN management and of course in the world of service we deal with both logical and physical configuration management (Serial Numbers / Lot Numbers are what we “routinely” schedule for maintenance / inspection / service and “non-routinely” repair / overhaul or modify.

    Engineering eBOM, Manufacturing mBOM, Service sBOM are all related but potentially change for different reasons at different phases of their lifecycle.

    Applicability of a certain part, component, assembly, appliance to one or more logical assets may also change the mBOM or sBOM – but – per my university engineering 101 class (30 some years ago) a PN only rolls when FFF “significantly” changes.

    Now – does that mean any change in the eBOM constitutes a PN change – I think not – thus the reason we have dash numbers.

    In aerospace & aviation we have a formal process that is tied to regulatory approval processes where eBOM, mBOM and sBOM come together along with supply chain and service documentation (operating manuals, maintenance manuals, repair manuals, tasks, service bulletins, service information letters, illustrations, …) called Logistics Support Analysis (LSA) or more commonly in the military Integrated Logistics Support (ILS).

    Part of the LSA/ILS process is SLM design & development – namely Failure Mode, Effects & Criticality Analysis (FMECA), Level of Repair Analysis (LoRA), Maintenance Task Analysis (MTA), Reliability Centered Maintenance (RCM/RCMII SAE JA1011 / Maintenance Steering Group (MSG-3) which, at the end of the process delivers a “routine” inspection, servicing, & maintenance program (scheduled plan) called the Maintenance Planning Document (MPD) and the input for various maintenance, logistics and repair documentation (including the Illustrated Parts Catalog / Breakdown (IPC/IPD)).

    While keeping supply chain IT systems up to date on the manufacturing side is complex enough – add in multiple vendors of the same FFF part and multiple PN (asset OEM PN different from Tier 2/3 OEM vendor PN different from PMA vendor PN (and the terrible habit of CPNs vs MPNs) and you have a serious nightmare PDM challenge.

    Again, at least in the aerospace, aviation & military domains – as OEMs have moved more into the SLM domain to capture the more lucrative after sales bundled services market – asset OEMs and some component OEMs are learning valuable lessons and changing policy and process accordingly.

  • beyondplm

    Michael, thanks for such an interesting insight and comment! Absolutely, service (SLM) is an addition to Part Management. This is would be a topic for another post, for sure :) . For the moment, my point was about PDM specifically and complexity of revision- and effectivity-based lifecycle management in one system.

  • pgarrish

    A lot of the issues come from 2 things. Firstly – cost. The simplest, most robust approach, would be re-number everything when it changes. You release a drawing as number X, if you change it you give it a new ID. Similarly when you change a part, or a spec etc etc.. The trouble is that because everything is inter-related, you have to change the referring items – assembly ID if you change a part, spec index if you change a spec etc. – and that is prohibitvely expensive in the current systems which are not set up to automate those tasks.

    Secondly, its not how it used to be done. Engineering owned the part number, planning/production had their own revisioning system – for instance when Condition of Supply changes. PLM and ERP are setup with this in mind – one creates the ID and is the only system that can change it, whether that is appropriate in all cases or not – so processes are created to bypass it, for good or bad.

    For those people who live ‘in’ the system, I think it would be fairly cheap to generate many more IDs and have the system refactor those references as required. But for those that live ‘outside’ the system – suppliers, 2D users etc – the final deliverable needs to be uniquely identifiable and self-sufficient WITHOUT recourse to ‘the system’ (PLM, ERP, whatever) or else they will use off-line copies and excel.

    It needs quite a change in focus from all the vendors and the users, to enable and trust the system to change references automatically, but that would leave time to change the things that need manual intervention and assess the true impact of the changes.

  • beyondplm

    Pgarish, you are right! in an ideal world, we would be looking how to keep “right references” between every related piece. However, even simple test with checkin/checkout/release of CAD assemblies and drawings will lead you to the situation when you will have to decide how to keep separate versions for parts, subassemblies and assemblies. Things are getting even more complex when it comes to parts vs. documents. When you get into ERP integration, you can totally mess up with documents, parts, versions, identifications and part numbers. It doesn’t work automagically. At least I haven’t seen any system that can cope with this and re-number everything and keep right references in place. If you know one, let me know :) . Thanks, Oleg

  • http://www.eng-eng.com/ Ed Lopategui

    It’s amazing that even after all these years, we still get wrapped around the pole with respect to interchangeability. Part of the problem lies in the fact that while the technology to actually make the part changes in CAD have accelerated, the capability to propagate those changes with respect to interchangeability at a product level have not kept pace. So it’s really easy to generate a bunch of changes and not know which end is up, especially if the handoff to the ERP side is not clean.

    I think GM’s failure that Michael mention is illustrative of the problem and is smoking gun evidence that manufacturing has reached the scale where we need better tools to manage parts en masse. GM has one heck of a PLM budget, so no doubt they had all the toys. We can say that it was a failure of governance of people/process, but in part an effective IT system should simplify and not complicate the matter. I too would love to see a forensic analysis… Of course no one on the outside will ever see that. And that’s a shame, because there are important lessons there that will remain forever opaque.

    With regard to FFF and “significant” change, the definition of significant is almost always trouble. The problem is very few changes are truly insignificant, and sometimes what seems a safe assumption later results in a defect or failure rate that defines that change as very much non-interchangeable. To cover those scenarios, requires overlaying effectivity models, lot numbers and all those other solutions that multiply complexity and cost. And this problem lies not only in the detail part but where to draw the line as you traverse product structure up to the end item level. Often arbitrary cutoffs of interchangeability also cause problems. It can be overwhelming even to the most diligent of cultures which is why we see so many problems. For smaller manufacturers especially this all might seem insurmountable, and you see quite a few brute force compromises.

    I would also consider a dash number a new PN, yes? Still defined by the same drawing, but it will be separately binned and can have its own effectivity. Not really a revision, because dash numbers can have independent history. I have often seen many large drawing with dozens if not hundreds of dash numbers describing dramatically different parts, that were grouped together on little more than the fact that most of them would be bent up sheet metal versus 3-axis machinings.

  • beyondplm

    Ed, thanks for the comment and insight! Money can fix technology, but rarely can fix people’s behavior. So, regardless on PLM budget, people and siloed organization can screw up any process – I’ve seen it many times. The challenge of propagating communication between departments and system is huge. I’m still looking for technology that will improve that, but fundamental behavior remains the same — http://beyondplm.com/2010/03/05/the-ugly-truth-about-plm-erp-monkey-volleyball/

    Interchangeability and revision is truly important topic. The way people manage it is so different depends on practices and organization. And it is ended up with people again that disagree on interchangeability rules.

  • Michael Wm. Denis

    Oleg Shilovitsky got a couple of Beyond “basic” PLM questions on where and how “part” information is stored.

    In S1000D (and I believe ISO 10303) the decomposition of “structural” configuration follows the following construct of:
    System – Sub-System – Sub-sub-system – component – assembly – parts.

    NOTE: in aviation FAA & EASA regulations we also have this poorly defined term “appliance” – which I’ll ignore for now.

    Each of these have “functional” configurations (parameters and specifications)

    Example: APU – Power Generator – Starter – Starter Motor – various parts in the assembly

    Lets say the Starter component has the following “functional” parameters (attributes) and specifications (enumeration or values):

    Mass in kilograms
    Min Input Voltage in volts
    Min Input Amperage in amps
    Min Breaking Torque in ft-lbs (where speed = 0)
    Min Speed in revolutions per second (RPS)
    and each of these could also have maximums and modes/medians/means

    Q1) where are these functional parameters codified and stored? CAD, CAM, CAE, PLM – both CAD and PLM?

    Q2) are they stored as “string” or “char” datatypes or more specific datatypes (integer, decimal, float, Boolean, datetime, …)?

    Q3) how are the UOM (Units of Measure) codified and stored? (i.e., feet, meters, inches, centimeters, volts, kilovolts, galUS, galUK, tonUS, tonMetric, …)

    Change in Form, Fit or Function

    Assume that the component “Starter Motor” has a specific geometry form and fit to the higher level sub-system “Power Generator” and that there is a change in a “part” in the assembly (changed the metallurgy of the magnets) such that the mass, form and fit of said assembly part “B” is the same as part “A” – BUT – the resultant Min Breaking Torque of the component does change (increases) – THEN –

    Q4) would you say “good engineering practice” dictates the PN of the “Starter Motor” stays the same and only the “dash” number rolls?
    Note: obviously the PN of the magnets did roll as their form and functional specification UOM Gauss or Tesla (10,000 Gauss) did change.

    Q5) would the drawing diagram not change but the codification of the functional parameters change – thus a new version of the same drawing number be “checked into” the CAD or PLM (which) systems?

    Q6) if both old and new “Starter Motor” dash number specifications are allowable structural configurations with different functional configuration both “applicable” to a higher level assembly (sub-system or system) but with different situational preferences (neither is universally a primary component) – how do you designate this? (use case may be the need for the improved part for operators of the APU / Aircraft in cold weather environments)

    Q7) General question – is it good engineering practice – to roll a PN or Dash number with every change in a drawing number? (seems not)

    Q8) If the answer to Q7 is no – THEN – is it NOT good engineering practice (bad practice) to codify PN with drawing numbers? (which is what I believe the point of your blog is)

  • Michael Wm. Denis

    @edwardlopategui:disqus there should be a “Like” button for individual entries such as yours below (action item Oleg @beyondplm:disqus )

  • http://www.eng-eng.com/ Ed Lopategui

    Thanks Michael, your words are certainly better than a like.

    I worked many Part 25 programs in the past so I feel your pain.

    BTW Disqus comments have an up/down vote system. You can see it in the lower left hand corner of each post. It’s a little obtuse, I know.

  • http://www.eng-eng.com/ Ed Lopategui

    I’ll get started with 1-3

    A1: Attribute data in the PLM is the right place to put it, which then could be associatively inked in the CAD file. Often times, however, I see many companies just put dumb text on a drawing or bury it in a separate spec document.

    A2: That depends how the PLM data model has been configured or customized. All of the above are possible in most modern platforms.

    A3: Typically the data model has a specific table reserved for UOM, and it can be extended as necessary. Most of the PLM platforms have the standard units configured OOTB.

  • beyondplm

    Michael, thanks for posting these questions and use-cases. You’re clearly flying beyond what DISQUS can handle in terms of “structured discussion”.

    Nevertheless, few answers:
    1- probably requirements management or PLM, which supposed to be expanded to handle different product representations (functional, logical, physical)

    2/3- agree with Ed. companies are not following strict UOM policies. You can see lots of text strings. To handle UOM carefully is a lot of work and many data management systems are doing poor job by using strings for everything.

    5- I’ve seen many cases when drawing is not changing in case diagram remains the same.

    7- probably not.

    8- I’d not recommend to use the same code for PN and drawing number. But it requires very good system of references and links.

  • beyondplm

    It looks like RFE for DISQUS :) .

  • Pingback: Mavericks of Engineering Change | E(E)

Previous post:

Next post: